UCF STIG Viewer Logo

The use of Digital Certificates must be implemented in accordance with security requirements.


Overview

Finding ID Version Rule ID IA Controls Severity
V-3225 ITNT0040 SV-7144r4_rule DCCS-1 DCCS-2 ECCD-1 ECCD-2 Medium
Description
Digital certificates are a primary requirement for Secure Sockets Layer (i.e., SSL). The origin of a certificate, the Certificate Authority (i.e., CA), is crucial in determining if the certificate should be trusted. Failure to maintain a list of appropriate host-based CA certificates could result in unauthorized access to the host. Certificate name filtering is a facility that allows multiple certificates to be mapped to a single ACP userid. Rather than matching a certificate stored in the ACP to determine the userid, criteria rules are used. Depending on the filter criteria, a large number of client certificates could be mapped to a single userid. Failure to properly control the use of certificate name filtering could result in the loss of individual identity and accountability.
STIG Date
z/OS TSS STIG 2015-06-24

Details

Check Text ( C-25076r4_chk )
NOTE: The procedures in this checklist item presume the domain being reviewed is running releases of z/OS, and use the ACP as the certificate store.

Self-Signed Certificates

If the domain being review is not a production system and is only used for test and development, this Self-Signed Certificates review can be skipped.

TSS LIST(ACIDS) DIGICERT(ALL)

___ If certificate information is not found from the above command, this is not a finding.

NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks.

The following command is issued for each user identified in the TSS LIST(ACIDS) DIGICERT(ALL) command:

TSS LIST(user) DIGICERT(ALL)

___ If the digital certificate information indicates that the issuer’s distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA) , this is not a finding. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Examples of an acceptable DoD CA are:
DoD PKI Class 3 Root CA
DoD PKI Med Root CA

An example of a self-signed certificate would be site information displayed as the issuer’s distinguished name.

Using the ACID(s) assigned to the TCP/IP address space(s), issue the following TSS command to list any associated key rings:

TSS LIST(tcpip acid) KEYRING(ALL)

For each Certificate Owner, issue the following TSS command to list the certificate(s) associated with their ACID:

TSS LIST(cert owner acid) DIGICERT(ALL)

___ If the digital certificate information indicates that the issuer’s distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), this is not a finding. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

___ If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a finding.

DoD PKI Root Certificate Authority

If the domain being review is not a production system and is only used for test and development, this DoD PKI Root Certificate Authority review can be skipped.

Issue the following TSS command to list the Certificate Authorities:

TSS LIST(CERTAUTH) DATA(ALL)

___ If certificate information is not found from the above command, this is not a finding.

NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks.

___ If the digital certificate information indicates that all certificates lead to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), this is not a finding. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Examples of an acceptable DoD CA are:
DoD PKI Class 3 Root CA
DoD PKI Med Root CA

___ If the digital certificate information indicates that any certificate is from a non-DoD entity (e.g., VeriSign, Thawte, IBM World Registry) and the Status is TRUST, this is a finding.

Certificate Name Filtering

If certificate name filtering is in use, the IAM should document each active filter rule and have written approval to use the rule.

Issue the following TSS command to list any certificate name filters defined to TSS:

TSS LIST(SDT) CERTMAP(ALL)

___ If there is nothing to list, there is not a finding.

NOTE: Certificate name filters are only valid when their Status is TRUST. Therefore, you may ignore filters with the NOTRUST status.

If certificate name filters are defined and they have a Status of TRUST, certificate name filtering is in use.

___ If certificate name filtering is in use and filtering rules have been documented and approved by the IAM, there is not a finding.

___ If certificate name filtering is in use and filtering rules have not been documented and approved by the IAM, this is a finding.
Fix Text (F-20526r2_fix)
Review the list of host-based CAs and ensure they are limited to those with a trust hierarchy that leads to a DOD PKI Root CA. Ensure any certificate name filtering rules in use are documented and approved by the IAM. 1. Consult the CA-TSS documentation, specifically the Cookbook regarding usage of the TSS commands to administer PKI Certificates. 2. Contact the CIO office (CI32) for information on DoD PKI Certificates and the most current guidelines. 3. The information on IASE website must be reviewed to ensure that certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).